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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief History 



The present document is one of a series of ECMA Standards defining the interworking of services and signalUng 
protocols deployed in Corporate telecommunication Networks (CN). The series uses telecommunication concepts as 
developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as 
defined by ISO/IEC. It has been produced under ETSI work item DEN/ECMA-00193. 

The present document defines the signalling protocol interworking for the generic functional procedures in support of 
Supplementary Services and/or Additional Network Features (ANFs) between a Private Integrated Services Network 
(PISN) and a private telecommunications network based on the Internet Protocol (IP). It is further assumed that the 
protocol for the PISN is that defined for the Q reference point (QSIG) and the protocols for the IP based network are 
based on ITU-T Recommendation H.323 [6]. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTCl, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document has been adopted by the ECMA General Assembly of June 2000. 
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1 Scope 



The present document specifies signalling interworking between "QSIG" and "H.323" in support of generic functional 
procedures for supplementary services within a Corporate telecommunication Network (CN). 

"QSIG" is a signalling protocol that operates at the Q reference point between Private Integrated Services eXchanges 
(PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in ECMA-133 [1]. A 
PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified in other 
ECMA Standards, in particular ECMA-143 [2] (call control in support of basic services), ECMA-165 [3] (generic 
functional protocol for the support of supplementary services) and a number of standards specifying individual 
supplementary services. 

"H.323" is a set of signalling protocols for the support of voice or multimedia communication within a packet network, 
in particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 
signalling protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or 
directly. An endpoint can be a terminal or a gateway to another network. H.323 is an "umbrella" recommendation, 
referring to various ITU-T recommendations, in particular Recommendations H.225.0 [4] and H.245 [5] (basic 
communication capabilities) and Recommendation H.450. 1 [7] (generic functional protocol for the support of 
supplementary services). 

NOTE: H.450. 1 applies to the 1998 version of H.323 (also known as H.323 version 2) and to later versions. 

Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of an IP 
network, or a call originating at a user of an IP network to terminate at a user of a PISN. In addition the present 
document enables the participants of a call to exchange supplementary service control information in a generic way. 
The more specific aspects of interworking particular supplementary services are specified in other ECMA Standards. 

The present document is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG 
and an IP network employing H.323. 



Conformance 



In order to conform to the present document, a gateway shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 
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4 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

4.1 External definitions 

The present document uses the following terms defined in other documents: 

Endpoint: (ITU-T Recommendation H.323) 

Gatekeeper: (ITU-T Recommendation H.323) 

Private Integrated services Network eXchange (PINX): (ECMA-133) 

Switched Circuit Network (SCN): (ITU-T Recommendation H.323) 

Additionally the definitions of ECMA-165 [3] and ITU-T Recommendation H.450.1 [7] shall apply, as appropriate. 

4.2 Other definitions 
4.2.1 Call, Basic call 

A call in the sense of QSIG (see ECMA-143), and a (point-to-point) conference in the sense of H.323 
(see ITU-T Recommendation H.323). 

NOTE: A "call" in the sense of H.323 is that segment of a (point-to-point) conference which belongs to the H.323 
domain. In a multipoint conference the H.323 segment of each conference leg is a separate call. 
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4.2.2 Corporate telecommunication Network (CN) 

Sets of equipment [Customer Premises Equipment and/or Customer Premises Networks] which are located at 
geographically dispersed locations and are interconnected to provide telecommunication services to a defined group of 
users. 

NOTE: A CN can comprise a PISN, a private IP network (intranet), or a combination of the two. 

4.2.3 Gateway 

A gateway as defined in H.323, here specifically for the purpose of interworking with a network employing QSIG. 

4.2.4 IP network 

A public or private network offering connectionless packet-mode services based on the Internet Protocol (IP) as the 
network layer protocol. 

4.2.5 Private Integrated Services Network (PISN) 

A private switched circuit network (SCN). 

4.2.6 Receiving side 

Within the context of a single information exchange through a gateway, the side of the gateway where the information 
arrives. 



4.2.7 Sending side 



Within the context of a single information exchange through a gateway, the side of the gateway where the information 
is transmitted. 

4.2.8 Side 

A single protocol stack (QSIG or H.323) within a gateway. 



Acronyms 



APDU 

ASE 

CN 

GET 

GK 

ICS 

IE 

IP 

IPL 

IWF 

LAN 

MCU 

PINX 

PISN 

ROSE 

SCM 

SCN 

ss 

TCP 

TE 



Application Protocol Data Unit 

Application Service Element 

Corporate telecommunication Network 

Generic Functional Transport 

GateKeeper 

Implementation Conformance Statement 

Information Element 

Internet Protocol 

Inter-PINX Link 

InterWorking Function 

Local Area Network 

Multipoint Control Unit 

Private Integrated services Network eXchange 

Private Integrated Services Network 

Remote Operations Service Element 

Signalling Carriage Mechanism 

Switched Circuit Network 

Supplementary Service 

Transmission Control Protocol 

Terminal Equipment 
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UDP 



User Datagram Protocol 



Service description 



6.1 



The architecture of the two networks 



An H.323 arrangement consists of two or more H.323 endpoints connected to an IP network, e.g. a local area network 
(LAN). H.323 endpoints are terminals, gateways or multipoint control units (MCU). The arrangement may also contain 
one or more gatekeepers (GK). The underlying network's components (routers etc.), however, are of no concern with 
regard to H.323. 

A gateway permits interworking with switched circuit networks (SCN), e.g. a PISN. 

Gatekeeper Gateway 




Terminal 



Terminal 



Figure 1 : Example of an H.323 arrangement 

A Private Integrated Services Network (PISN) consists of one or more network exchanges (PINX) with attached 
terminals (TE). PINXs are inter-connected by inter-PINX links (IPLs). Communication requires a path to be set up 
between two TEs via PINXs and IPLs. 



PINX A 



IPL 



TE 



IPL 




PINXC 



IPL 



PINXB 



PINXD 




TE 



Figure 2: Exampie of a PiSN connection between two terminals 
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Comparing the two scenarios, the most significant difference is the absence of nodal entities in the H.323 case. 
Communication is an exchange of information packets directly between two or more endpoints. A gatekeeper, if 
present, has certain assisting tasks, but does not "switch" any payload channels. It may, however, relay signalling 
information between endpoints or act upon it on behalf of endpoints. 

In the PISN case, information channels are switched by PINXs between communicating terminals for the duration of 
the communication. The PINXs where the communicating terminals are attached are end PINXs, which act on user 
requests and are in control of the connection through the PISN. If more than 2 PINXs are present in a call path, the 
intermediate PINXs act as transit or relay nodes for both signalling and user information (payload). This role 
sharing - TE, end PINX, transit PINX - does not exist in a pure H.323 conversation. 

These structural differences between H.323 and PISN will in many cases result in a different allocation of 
supplementary service functionality in the two environments. The possibly different function split must be taken into 
account when individual supplementary services are interworked. 

6.2 Generic procedures: Capabilities 

Generic procedures provide the transport protocol for supplementary service control information. Supplementary 
service control protocols are based on remote operations (ROSE) as defined in ITU-T Recommendation X.219/X.229 
(blue book) and X.880 series. 



Generic procedures for PISNs (QSIG-GF) are specified in ECMA-165 [3]. For the H.323 environment, generic 
procedures are specified in ITU-T Recommendation H.450.1 [8]. 

Table 1 compares the capabilities of QSIG-GF and H.450.1. 

Table 1 : Capabilities 



Capability 


QSIG-GF 


H.450.1 


Remarks 


Call related transport 


• 


• 




Call independent connection oriented 
transport 


• 


•/ 




Call independent connectionless 
transport 


• 


- 


Currently not used by standardized 
OSIG supplementary services. 


Network Facility Extension (NFE) 


• 


•/ 


Extended addressing capabilities in 
H.450.1. 


Interpretation APDU 


■/ 


■/ 




ROSE APDUs and procedures 


X.21 9/229 


X.880 series 


In practice no relevant difference. 


Other APDUs and procedures: DSE 
(dialogue procedures), ACSE 


■/ 


- 


Currently not used by standardized 
OSIG supplementary services. 


Manufacturer specific information 


■/ 


■/ 


2 alternative containers in H.450.1. 


Notifications 


■/ 


- 




Messages 


ALERTING 

CONNECT 

DISCONNECT 

PROGRESS 

RELEASE, REL. 

COMP., SETUP 

FACILITY 

NOTIFY 


ALERTING 
CALL PROC. 
CONNECT 

PROGRESS 

REL. COMP. 

SETUP 

FACILITY 


These OSIG messages are defined in 

ECMA-143[9]. 

All messages for H.450.1 transport are 

defined in H.225.0 [4]. 

These OSIG messages are defined in 
ECMA-165 [3]. 


Information elements 


Facility 

Notification 

indicator 


User-user 
information 


Element H 450.1 Supplementary 
Service APDU within User-user 
information is the equivalent of 
information element Facility. 


ASN.1 encoding rules 


X.208 
X.209 BER 


X.680 series 
X.691 PER 
(BAV) 


BER - Basic Encoding Rules. 
PER - Packed Encoding Rules. 
BAV - basic aligned variant. 
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Table 1 shows that the capabihties currently used by standardized supplementary services are supported in both 
environments (exception; notifications are currently not used in H.450. However, in many cases an equivalent operation 
exists in an H.450 supplementary service). An interworking or mapping is therefore generally possible although details 
may be different. 

NOTE: The NOTIFY message is optional in H.225.0 and may be passed on by a gateway to the H.323 side, but 
its processing is unspecified - it may be meaningless. In the other direction, current H450.X services do 
not generate notifications. 



6.3 



Protocol model 



QSIG-GF defines a protocol model which can be applied to H.450. 1, too (see figure 3). 

The shaded areas in figure 3 are specific to GF and are defined in ECMA-165 [3]. Call control and the non-shaded part 
of protocol control represent the basic call protocol as defined in ECMA-143 [2]. SS-control parts are defined in 
individual supplementary service standards. SCM is any suitable layer 2 protocol, dependent on the scenario in which 
QSIG is used. 

NOTE: Some parts of the QSIG-GF protocol model, e.g. the DSE element, are omitted from figure 3 for clarity. 

In the H.450. 1 case call control and protocol control include H.225.0 and possibly H.245 signalling (the latter is not 
required by H.450. 1 per se). The signalling carriage mechanism is an IP protocol stack, usually TCP (and/or UDP) on 
top of IP. The shaded areas are GF specific and are implicitly contained in H.450. 1 (and partly in H.225.0). 



Call 
Control 



Coordination 
Function 



SS-Control#l 



SS-Control#n 



ROSE 



OFT Control 



Protocol Control 



Signalling Carriage 
Mechanism (SCM) 



Figure 3: Protocol model 
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6.4 Interworking of supplementary services 

The interworking function (IWF) sits above the application service elements (ASE), which comprise the coordination 
function, ROSE and SS Control. The gateway has to support both protocol versions of the supplementary service 
syntactically and semantically. It represents on each side one of the functional roles specified for the supplementary 
service (usually a different one on each side — for example, the gateway may look like the terminating PINX on its 
PISN side and like the originating endpoint on its H.323 side). Depending on the individual supplementary service, the 
gateway may have to provide functions that are interworking specific, in addition to the procedures specified by the 
supplementary service itself. 

The present document specifies generic requirements for the IWF. For a given supplementary service additional 
requirements of the IWF can be specified separately, e.g., in another standard. 



PINX 



ASE SS-Control / 
ROSE /Coord. 
Function 



QSIG OFT Control 



QSIG Protocol Control 



Signalling Carriage 
Mechanism (SCM) 



Gateway 
Interworking Function (IWF) 



ASE SS-Control/ 
ROSE /Coord. 
Function 



ASE SS-Control/ 
ROSE / Coord. 
Function 



QSIG GET Control 



QSIG Protocol Control 



H.450 GET Control 



H. 225.0 Protocol Control 



Signalling Carriage 
Mechanism (SCM) 



IP Stack 



H.323 Terminal 



ASE SS-Control/ 
ROSE /Coord. 
Function 



H.450 GET Control 



H. 225.0 Protocol Control 



IP Stack 



Figure 4: Interworking 



7 Protocol interworking - Messages and information 

elements 

When providing interworking for a specific supplementary service, each side of a gateway shall act according to the 
requirements of the supplementary service protocol in force on that side. In addition, the gateway shall provide the 
interworking function that controls and co-ordinates the two sides of the gateway. 

NOTE: This means the gateway will act as source PINX or as destination PINX on its QSIG side, and as source 
endpoint or as destination endpoint on its H.323 side. 

In the absence of more specific rules mandated by a supplementary service specific interworking specification, a 
gateway shall: 

if the content - e.g. APDU(s) of supplementary service operation(s) - of a received message is understood and 
can be passed on (in the form of equivalent information), behave in accordance with the rules of table 2, by 
carrying out the required action when a given condition occurs. Each condition applies to either the receipt of an 
H.323 message from an entity in the IP network or the receipt of a QSIG message from a PINX; 

if the content is understood but cannot be passed on, discard the information and act in accordance with the rules 
of the supplementary service concerned; 

if an invoke APDU of an unrecognized operation is encountered, act according to the interpretation APDU; in 
the absence of an interpretation APDU, send back a reject APDU "unrecognizedOperation". 
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NOTE 1 : The rules below cover both call related and call independent signalling. 

NOTE 2: It is recommended that supplementary service specific interworking standards take these rules as a basis 
and modify them or add to them only when necessary. 

NOTE 3: It is not precluded that an implementation handles additional cases by refining these rules, e.g. sending a 
FACILITY message if the intended basic call control message is not appropriate at the time. Such 
behaviour is outside the scope of the present document. 

Table 2: Generic Message and APDU handling requirements 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 ALERTING, CONNECT, or 
PROGRESS message containing one or more 
H4501SupplementaryService APDU(s) witliin tlie 
User-user information element 


If a OSIG ALERTING, CONNECT, or PROGRESS 
message is to be transmitted, include in this OSIG 
message one or more Facility information element(s) with 
content equivalent to that of the 
H4501 SupplementaryService APDU(s) 


2 


Receipt of an H.323 SETUP message containing one or 
more H4501SupplementaryService APDU(s) within the 
User-user information element 


If a OSIG SETUP message is to be transmitted, include in 
this OSIG message one or more Facility information 
element(s) with content equivalent to that of the 
H4501 SupplementaryService APDU(s) 


3 


Receipt of an H.323 CALL PROCEEDING message 
containing one or more H4501SupplementaryService 
APDU(s) within the User-user information element 


Transmit a OSIG FACILITY message containing one or 
more Facility information element(s) with content 
equivalent to that of the H4501 SupplementaryService 
APDU(s) if the OSIG call state permits 


4 


Receipt of an H.323 RELEASE COMPLETE message 
containing one or more H4501SupplementaryService 
APDU(s) within the User-user information element 


If clearing is not already in progress on the OSIG side, 
transmit a OSIG DISCONNECT, RELEASE or RELEASE 
COMPLETE message, whichever is appropriate for the 
OSIG call state, containing one or more Facility 
information element(s) with content equivalent to that of 
the H4501 SupplementaryService APDU(s) 


5 


Receipt of an H.323 FACILITY message containing one 
or more H4501 SupplementaryService APDU(s) within 
the User-user information element 


Transmit a OSIG FACILITY message containing one or 
more Facility information element(s) with content 
equivalent to that of the H4501 SupplementaryService 
APDU(s) if the OSIG call state permits 


6 


Receipt of a OSIG ALERTING, CONNECT, or 
PROGRESS message containing one or more Facility 
information element(s) 


If an H.323 ALERTING, CONNECT, or PROGRESS 
message is to be transmitted, include within the 
User-user information element in this message one or 
more H4501 SupplementaryService APDU(s) with content 
equivalent to that of the Facility information element(s) 


7 


Receipt of a OSIG SETUP message containing one or 
more Facility information element(s) 


If an H.323 SETUP message is to be transmitted, include 
within the User-user information element in this message 
one or more H4501 SupplementaryService APDU(s) with 
content equivalent to that of the Facility information 
element(s) 


8 


Receipt of a OSIG DISCONNECT, RELEASE or 
RELEASE COMPLETE message containing one or 
more Facility information element(s), as the first call 
clearing message 


If clearing has not already taken place on the H.323 side, 
transmit an H.323 RELEASE COMPLETE message 
containing within the User-user information element one 
or more H4501 SupplementaryService APDU(s) with 
content equivalent to that of the Facility information 
element(s) 


9 


Receipt of a OSIG RELEASE or RELEASE COMPLETE 
message containing one or more Facility information 
element(s), as a subsequent call clearing message 


Ignore 


10 


Receipt of a OSIG FACILITY message containing a call 
reference other than the dummy call reference and one 
or more Facility information element(s) 


Transmit an H.323 FACILITY message containing within 
the User-user information element one or more 
H4501 SupplementaryService APDU(s) with content 
equivalent to that of the Facility information element(s) if 
the H.323 call state permits 


11 


Receipt of a OSIG FACILITY message containing the 
dummy call reference 


Ignore 


12 


Receipt of a OSIG NOTIFY message 


Ignore 


13 


Receipt of a OSIG message, other than NOTIFY, 
containing a Notification indicator information element 


Ignore the Notification indicator information element 
(further actions to be taken are those required by basic 
call interworking rules or by rules 1 through 10 above) 
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Rule 


Condition 


Required action 


14 


Receipt of an H.323 SETUP message for a call 
independent signalling connection 


Transmit a QSIG SETUP message for a call independent 
signalling connection if possible (rule 2 applies if 
supplementary service information is present) 


15 


Receipt of a QSIG SETUP message for a call 
independent signalling connection 


Transmit an H.323 SETUP message for a call 
independent signalling connection if possible (rule 7 
applies if supplementary service information is present) 



8 



Protocol interworking - Content of information 
elements 



8.1 Content mapping from QSIG to H.323 

Unless a specific supplementary service interworking standard mandates a different mapping, a gateway, when 
transmitting an H4501SupplementaryService APDU within the User-user information element as a result of receiving a 
QSIG Facility information element, shall map elements in accordance with table 3 by carrying out the required action 
when a given condition occurs. 

In the table, "(M)" denotes a mandatory element, and "(C)" denotes a conditionally mandatory element, meaning that 
the element is part of another optional element of type SEQUENCE or SET and shall be included if the enclosing 
element is included. 

NOTE: The QSIG Facility information element adheres to the Q.93 1 coding rules of separate octet groups, with 
some octet groups being ASN.l encoded, whereas the H.450.1SupplementaryService APDU is a single 
structure fully defined in ASN. 1 . 

Table 3: Mapping from QSIG Facility information element 
to H.323 H4501SupplementaryService APDU 



QSIG element name 


H.323 element name 


Mapping requirement 


networkFacility Extension 


networkFacility Extension 


(see note). 


sourceEntity (0): 
endPINX 
anyTypeOfPINX 


sourceEntity (C): 
endpoint 
anyEntity 


Generate as required, or map without change 
(type ENUMERATED vs. type CHOICE with 
alternatives of type NULL). 


sourceEntityAddress 


sourceEntityAddress 


Generate as required, or map from type 
PartyNumber to type AliasAddress.partyNumber 
according to table 5. 


destinationEntity (C): 
endPINX 
anyTypeOfPINX 


destinationEntity (C): 
endpoint 
anyEntity 


Generate as required, or map without change 
(type ENUMERATED vs. type CHOICE with 
alternatives of type NULL). 


desti nation Entity Address 


destinationEntity Address 


Generate as required, or map from type 
PartyNumber to type AliasAddress.partyNumber 
according to table 5. 


Network Protocol Profile 


- 


No mapping required. Discard whole Facility IE. 


Interpretation APDU 


interpretationApdu 


Generate as required, or map without change 
(type ENUMERATED vs. type CHOICE with 
alternatives of type NULL). 


Service APDU(s) (M) 


serviceApdu (M) 


Map every ROSE APDU separately according to 
the respective interworking standard. Discard 
APDUs for which no mapping rules are available. 
Discard whole Facility IE if no APDUs are 
mappable (i.e. if serviceApdu would become an 
empty SEOUENCE). 


NOTE: The NFE shall be processed on the receiving side as specified in ECMA-165 [3]. An NFE shall be inserted on 
the sending side according to the requirements of the respective supplementary service protocol. Usually no 
mapping will occur. 
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8.2 Content mapping from H.323 to QSIG 

Unless a specific supplementary service interworking standard mandates a difl^erent mapping, a gateway, when 
transmitting a QSIG Facility information element as a result of receiving an H4501SupplementaryService APDU within 
the User-user information element, shall map elements in accordance with table 4 by carrying out the required action 
when a given condition occurs. 

In the table, "(M)" denotes a mandatory element, and "(C)" denotes a conditionally mandatory element, meaning that 
the element is part of another optional element of type SEQUENCE or SET and shall be included if the enclosing 
element is included. 

NOTE; The H.450.1SupplementaryService APDU is a single structure fully defined in ASN.l, whereas the QSIG 
Facility information element adheres to the Q.93 1 coding rules of separate octet groups, with some octet 
groups being ASN.l encoded. 

Table 4: Mapping from H.323 H4501SupplementaryService APDU to 
QSIG Facility information element 



H.323 element name 


QSIG element name 


Mapping requirement 


networkFacility Extension 


Network Facility Extension 


(see note). 


sourceEntity (C): 
endpoint 
anyEntity 


sourceEntity (C): 
endPINX 
anyTypeOfPINX 


Generate as required, or map witfiout cfiange (type 
CHOICE with alternatives of type NULL vs. type 
ENUMERATED). 


sourceEntityAddress 


sourceEntityAddress 


Generate as required, or map from type 
AliasAddress.partyNumber or AliasAddress.el 64 to 
type PartyNumber according to table 6. Do not map 
otfner alternatives of CHOICE type AliasAddress. 


destination Entity (C): 
endpoint 
anyEntity 


destinationEntity (C): 
endPINX 
anyTypeOfPINX 


Generate as required, or map witfiout cfiange (type 
CHOICE witfi alternatives of type NULL vs. type 
ENUMERATED). 


desti nation Entity Address 


destinationEntity Address 


Generate as required, or map from type 
AliasAddress.partyNumber or AliasAddress.el 64 to 
type PartyNumber according to table 6. Do not map 
otfier alternatives of CHOICE type AliasAddress. 


interpretationApdu 


Interpretation APDU 


Generate as required, or map witfiout cfiange (type 
CHOICE witfi alternatives of type NULL vs. type 
ENUMERATED). 


serviceApdu (M) 


Service APDU(s) (M) 


Map every ROSE APDU separately according to 
tfie respective interworking standard. Discard 
APDUs for wfiicfi no mapping rules are available. 
Discard wfiole H4501SupplementaryService APDU 
if no APDUs are mappable. 


NOTE: Tlie NFE sliall be processed on tine receiving side as specified in ITU-T Recommendation H. 450.1 [10]. An 
NFE sliall be inserted on tlie sending side according to tlie requirements of \.he respective supplementary 
service protocol. Usually no mapping will occur. 
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8.3 Mapping of generic elements 

8.3.1 Mapping of addressing elements from QSIG to H.323 

A gateway shall map an addressing element received within an APDU of a QSIG operation to an addressing element of 
the APDU of the equivalent H.323 operation, if such an element is available in this APDU, by choosing one of the 
alternatives given in table 5. Which alternative is to be chosen depends on the specific H.323 operation. 

NOTE: At the time of publication of the present document, not all alternatives listed in table 5 are used by 
standardized operations. 

Table 5: Mapping (within ROSE APDUs) from QSIG address element to H.323 address element 



QSIG element (ASN.1 type) 


H.323 element (ASN.1 type) 


Mapping requirement 


Address 


Address 


Map without change. 


PartyNumber 


AliasAddress.partyNumber 


Map without change to alternative 
partyNumber of CHOICE type AliasAddress. 


EndpointAddress. 
destinationAddress 


Map without change to alternative 
partyNumber of CHOICE type AliasAddress in 
component destinationAddress of 
EndpointAddress. This mapping shall be the 
default alternative (see note 1). 


EndpointAddress. 
remoteExtensionAddress 


Map without change to alternative 
partyNumber of CHOICE type AliasAddress in 
component remoteExtensionAddress of 
EndpointAddress (see note 1). 


PartySubaddress 


PartySubaddress 


Map without change. 


PresentationAllowedlndicator 


PresentationAllowedlndicator 


Map without change. 


PresentedAddressScreened 


PresentedAddressScreened 


Map without change. 


EndpointAddress 


Map PartyNumber, if present, to 
destinationAddress or 

remoteExtensionAddress as specified above. 
Map Screeninglndicator without change. 
Discard PartySubaddress if present. Optionally 
include Presentationlndicator (mandatory if 
number is restricted or not available) 
(see note 2). 


PresentedAddressUnscreened 


PresentedAddressUnscreened 


Map without change. 


EndpointAddress 


Map PartyNumber, if present, to 
destinationAddress or 

remoteExtensionAddress as specified above. 
Discard PartySubaddress if present. Optionally 
include Presentationlndicator (mandatory if 
number is restricted or not available) 
(see note 2). 


PresentedNumberScreened 


PresentedNumberScreened 


Map without change. 


EndpointAddress 


Map PartyNumber, if present, to 
destinationAddress or 

remoteExtensionAddress as specified above. 
Map Screeninglndicator without change. 
Optionally include Presentationlndicator 
(mandatory if number is restricted or not 
available) (see note 2). 
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QSIG element (ASN.1 type) 


H.323 element (ASN.1 type) 


Mapping requirement 


PresentedNumberUnscreened 


PresentedNumberUnscreened 


Map without change. 


EndpointAddress 


Map PartyNumber, if present, to 
destinationAddress or 

remoteExtensionAddress as specified above. 
Optionally include Presentationlndicator 
(mandatory if number is restricted or not 
available) (see note 2). 


NOTE 1 : If the gateway wants to include an additional address (e.g. its own) then this address shall be included in 

destinationAddress, and PartyNumber shall be mapped to remoteExtensionAddress. Otherwise 

PartyNumber shall be mapped to destinationAddress. 
NOTE 2: The additional elements required for this mapping are specified in the "Implementers Guide for H.323, 

H.225.0, H.245, H.246, H.235, H.450 Series, and H.341 Recommendations" published by ITU-T (2000). 

These elements will be included in the next edition of Recommendation H.450. 1. 
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8.3.2 Mapping of addressing elements from H.323 to QSIG 

A gateway shall map an addressing element received within an APDU of an H.323 operation to an addressing element 
of the APDU of the equivalent QSIG operation, if such an element is available in this APDU, by choosing one of the 
alternatives given in table 6. Which alternative is to be chosen depends on the specific QSIG operation. 

NOTE: At the time of publication of the present document, not all alternatives listed in table 6 are used by 
standardized operations. 

Table 6: Mapping (within ROSE APDUs) from 1-1.323 address element to QSIG address element 



H.323 element (ASN.1 type) 


QSIG element (ASN.1 type) 


Mapping requirement 


Address 


Address 


Map without change. 


AliasAddress.e164 


PartyNumber 


Map as an explicit number (type of 
number = E164 or PNP) if possible, else as an 
implicit number (type of number = unknown) if 
possible (i.e. numeric string whose length does 
not exceed the QSIG limit), otherwise discard. 


AliasAddress.partyNumber 


PartyNumber 


Map without change. 


AliasAddress.* 


- 


Other alternatives of AliasAddress are not 
mappable. 


EndpointAddress 


PartyNumber 


Map destinationAddress or 
remoteExtensionAddress (see note 1) as 
specified for AliasAddress above. 


PresentedAddressScreened 


Map destinationAddress or 






remoteExtensionAddress (see note 1) to 






PartyNumber as specified for AliasAddress 






above, taking into account the 






Presentationlndicator if available (see note 2). 






Map to numberNotAvailableDueTolnterworking 






if none of the AliasAddress elements is a 






number. Set Screeninglndicator to 






userProvidedNotScreened if not contained in 






EndpointAddress (see note 2), otherwise map 






without change. 


PresentedAddressUnscreened 


Map destinationAddress or 






remoteExtensionAddress (see note 1) to 






PartyNumber as specified for AliasAddress 






above, taking into account the 






Presentationlndicator if available (see note 2). 






Map to numberNotAvailableDueTolnterworking 






if none of the AliasAddress elements is a 






number. 


PresentedNumberScreened 


Map destinationAddress or 






remoteExtensionAddress (see note 1) to 






PartyNumber as specified for AliasAddress 






above, taking into account the 






Presentationlndicator if available (see note 2). 






Map to numberNotAvailableDueTolnterworking 






if none of the AliasAddress elements is a 






number. Set Screeninglndicator to 






userProvidedNotScreened if not contained in 






EndpointAddress (see note 2), otherwise map 






without change. 


PresentedNumberUnscreened 


Map destinationAddress or 






remoteExtensionAddress (see note 1) to 






PartyNumber as specified for AliasAddress 






above, taking into account the 






Presentationlndicator if available (see note 2). 






Map to numberNotAvailableDueTolnterworking 






if none of the AliasAddress elements is a 






number. 


PartySubaddress 


PartySubaddress 


Map without change. 


PresentationAllowedlndicator 


PresentationAllowedlndicator 


Map without change. 


PresentedAddressScreened 


PresentedAddressScreened 


Map without change. 


PresentedAddressUnscreened 


PresentedAddressUnscreened 


Map without change. 


PresentedNumberScreened 


PresentedNumberScreened 


Map without change. 
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H.323 element (ASN.1 type) 


QSIG element (ASN.1 type) 


Mapping requirement 


PresentedNumberUnscreened 


PresentedNumberUnscreened 


Map without change. 


NOTE 1 : If present, remoteExtensionAddress shall be chosen for mapping. In this case destinationAddress contains the 
address of a network entity, e.g. a gateway that "represents" this remote extension in the H.323 domain. 

NOTE 2 These additional elements are specified in the "Implementers Guide for H.323, H. 225.0, H.245, H.246, H.235, 
H.450 Series, and H.341 Recommendations" published by ITU-T (2000). They will be included in the next 
edition of Recommendation H.450. 1 . 



8.3.3 Mapping of embedded information elements 

A gateway shall map those QSIG information elements embedded within PSSlInformationElement in the APDU of a 
QSIG operation, which are also valid information elements in H.323, to the equivalent H.323 information elements 
embedded within H225InformationElement, if the APDU of the respective H.323 operation allows so. 

A gateway shall map those H.323 information elements embedded within H225InformationElement in the APDU of an 
H.323 operation, which are also valid information elements in QSIG, to the equivalent QSIG information elements, 
embedded in PSSlInformationElement, if the APDU of the respective QSIG operation allows so. 

8.3.4 IVIapping of manufacturer specific information from QSIG to H.323 

A gateway shall include any manufacturer specific information (MSI) received within an APDU of a QSIG operation in 
the APDU of the equivalent H.323 operation according to table 7. 

Table 7: Mapping of extensions from QSIG to H.323 



QSIG MSI (ASN.1 type) 


H.323 MSI (ASN.1 type) 


Mapping requirement 


Extension 


Extension 


Map without change 



8.3.5 Mapping of manufacturer specific information from H.323 to QSIG 

A gateway shall include any manufacturer specific information (MSI) received within an APDU of an H.323 operation 
in the APDU of the equivalent QSIG operation according to table 8. 

Table 8: Mapping of extensions from H.323 to QSIG 



H.323 MSI (ASN.1 type) 


QSIG MSI (ASN.1 type) 


Mapping requirement 


Extension 


Extension 


Map without change 


Nonstandard Param eter 


- 


Discard 



8.3.6 Mapping of names from QSIG to H.323 

A gateway shall map a name element received within an APDU of a QSIG operation to a character string element of the 
APDU of the equivalent H.323 operation, if such an element is available in this APDU, according to table 9. 

Table 9: Mapping of names from QSIG to H.323 



QSIG element (type) 


H.323 element (type) 


Mapping requirement 


Name 


BMPString 


Map content of NameData, if present and not 
presentation-restricted, interpreted according to 
the applicable character set, to the equivalent 
BMP (i.e. Unicode) string 
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8.3.7 Mapping of names from H.323 to QSIG 

A gateway shall map a character string element received within an APDU of an H.323 operation to a name element of 
the APDU of the equivalent QSIG operation, if such an element is available in this APDU, according to table 10. 

Table 10: Mapping of names from H.323 to QSIG 



H.323 element (type) 


QSIG element (type) 


Mapping requirement 


BMPString 


Name 


Map content to element NameSet.nameData of 
type NamePresentationAllowed, according to 
one of the supported character sets, and indicate 
the chosen character set in element 
NameSet.characterSet. Alternatively, if character 
set ISO 8859-1 is used, map to alternative 
NameData (of type NamePresentationAllowed). 
Truncate if the H.323 element is longer than 50 
characters 



8.4 Handling of ROSE APDUs 



The generation and mapping of invoke, return result and return error APDUs shall be in accordance with the procedures 
of the individual supplementary service on each side of the gateway and with the requirements of a specific mapping 
standard if such a standard exists. 

In the absence of more specific requirements, a reject APDU containing a non-empty invoke identifier shall be mapped 
to a reject APDU with the same problem code. A QSIG reject APDU with an empty invoke identifier (i.e. type NULL) 
shall be discarded when received. 

When sending an invoke APDU the gateway shall allocate a new invoke identifier from the range of identifiers 
available on the sending side, and map it to the invoke identifier received on the receiving side if the invoke APDU is 
sent as a result of receiving an equivalent invoke APDU on the other side. 

When sending a return result or return error APDU, the gateway shall follow normal ROSE procedures, i.e. include the 
same invoke identifier as received in the invoke APDU to which this response relates. This rule shall also apply to reject 
APDUs with a non-empty invoke identifier. 

NOTE: Generation of a reject APDU with empty invoke identifier on the QSIG side of the gateway is outside the 
scope of the present document. 
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Annex A (normative): 
ICS Proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the ICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed ICS. 



A.1 Introduction 

The supplier of an implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options have been implemented for a given specification. 

The ICS can have a number of uses, including use: 

- by the implementor, as a check list for implementations to reduce the risk of unintended non-conformance, 
e.g. through oversight; 

- by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
Standard's ICS proforma; 

- by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork can 
often be predicted from incompatible ICS; 

- by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the 
implementation. 



A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed format questionnaire divided into clauses each containing a group of individual items. Each 
item is identified by an item reference, the description of the item (question to be answered), and the reference(s) to the 
clause(s) that specifies (specify) the item in the main body of the present document. 

The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional 
status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this 
item is dependent on the support marked for the referenced item). 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

I irrelevant or out-of-scope - this capability is outside the scope of the standard to which this ICS 

proforma applies and is not subject to conformance testing in this context; 

M mandatory (the capability is required for conformance to the standard); 

N/A not applicable - in the given context, it is impossible to use the capability; no answer in the 

support column is required; 

O optional (the capability is not required for conformance to the standard, but if the capability is 

implemented it is required to conform to the specification in the present document); 
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0.<n> qualified optional - in this case, <n> is an integer that identifies a unique group of related 

optional items; if no additional qualification is indicated, the support of at least one of the 
optional items is required for conformance to the present document; otherwise, the qualification 
and logic of the selection among the optional items is defined below the table explicitly; 

X excluded or prohibited - there is a requirement not to use this capability in a given context. 

Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. 
Where a support column box is left blank, no answer is required. 

If a "prerequisite line" (see clause A.2.4) is used after a clause heading or table title, and its predicate is false, no answer 
is required for the whole clause or table, respectively. 

A.2.2 Additional Information 

Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of Additional Information may be entered next to any answer in the questionnaire, and may be 
included in items of Exception Information. 



A.2.3 Exception Information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> 
reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. 

An implementation for which an Exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 

A.2.4 Further indications of the ICS proforma tables 

In addition to the columns of a table, the following information may be indicated: 

Prerequisite line 

A prerequisite line after a clause heading or table title indicates that the whole clause or the whole table is not required 
to be completed if the predicate is false. 

Qualification 

At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the 
description of the status "qualified optional" in clause A.2.1. 

Comments 

This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided 
separately (without using this box). 
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A.3 Identification of the Implementation 



A.3.1 Implementation Identification 



Supplier (see note 1) 




Contact point for queries about tlie ICS (see note 1) 




Implementation Name(s) and Version(s) (see notes 1 
and 2) 




Other information necessary for full identification - 
e.g., name(s) and version(s) for machines and/or 
operating systems; System name(s) 




NOTE 1 : Only the first three items are required for all implementations; other information may be completed as 

appropriate in meeting the requirement for full identification. 
NOTE 2: The terms Name and Version should be interpreted appropriately to correspond with a supplier's terminology 

(e.g. Type, Series, Model). 



A.3. 2 Specification for which this ICS applies 



Title 


Corporate telecommunication networks - Signalling interworking 
between OSIG and H.323 - Generic functional protocol for the 
support of supplementary services 


Version 


1.0 


Corrigenda Implemented (if applicable) 




Addenda Implemented (if applicable) 




Amendments Implemented (if applicable) 




Have any exception items been required ? 


No[ ] Yes[ ] 

(The answer Yes means that the implementation does not 

conform to the present document) (see note) 


Date of Statement 




NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a separate 
sheet of paper: 
"Nature of non-conformance (if applicable):" 



A.4 Major capabilities 



Table A.1 : Major capabilities 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MC1 


support OSIG call related generic procedures 




0.1 


ECMA-165 


[ ]Yes [ ]No 


MC2 


support OSIG call independent connection 
oriented generic procedures 




0.1 


ECMA-165 


[ ]Yes [ ]No 


MC3 


support OSIG call independent 
connectionless generic procedures 







ECMA-165 


[ ]Yes [ ]No 


MC4 


support OSIG notification procedures 







ECMA-165 


[ ]Yes [ ]No 


MC5 


support H.450.1 generic procedures 




M 


H.450.1 


[]Yes 


MC6 


support protocol interworking 




M 


7 


[]Yes 


0.1 : Support of at least one of these capabilities is required. 


Comments: 
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A. 5 Message and information element handling 

Table A.2: Message and information element handling 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


Ml 1 


behave in accordance with rules 1 to 10 




M 


7 


[]Yes 


Ml 2 


behave in accordance with rule 1 1 


MC3 
NOT MC 3 


M 
N/A 


7 


[]Yes 
[]N/A 


MIS 


behave in accordance with rules 12 and 13 


MC4 
NOT MC 4 


M 
N/A 


7 


[]Yes 
[]N/A 


Ml 4 


behave according to the interpretation APDU 
when an unrecognized invoke APDU is 
encountered 




M 


7 


[]Yes 


MIS 


discard information that cannot be passed on 




M 


7 


[]Yes 














Ml 6 


behave in accordance with rules 14 and 15 


MC2 
NOT MC 2 


M 
N/A 


7 


[]Yes 
[]N/A 


Comments: 





A. 6 Mapping content of information elements 
A.6.1 Mapping content of elements from QSIG to H.323 

Table A.3: Content mapping from QSIG to H.323 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


CM0 1 


map Facility information elements to 
H4S01 SupplementaryServiceAPDUs 




M 


8.1 


[]Yes 


CM0 2 


map addressing elements from OSIG to 
H.323 




M 


8.3.1 


[]Yes 


CM0 3 


map embedded information elements from 
OSIG to H.323 




M 


8.3.3 


[]Yes 


CM0 4 


map extensions from OSIG to H.323 




M 


8.3.4 


[]Yes 


CMOS 


map embedded names from OSIG to H.323 
strings 




M 


8.3.6 


[]Yes 


CM0 6 


map ROSE APDUs from OSIG to H.323 




M 


8.4 


[]Yes 


Comments: 
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A.6.2 Mapping content of elements from H.323 to QSIG 



Table A.4: Content mapping from H.323 to QSIG 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


CMH 1 


map H4501SupplementaryServiceAPDUs to 
Facility information elements 




M 


8.2 


[]Yes 


CMH2 


map addressing elements from H.323 to 
QSIG 




M 


8.3.2 


[]Yes 


CMH 3 


map embedded information elements from 
H.323 to QSIG 




M 


8.3.3 


[]Yes 


CMH 4 


map extensions from H.323 to QSIG 




M 


8.3.5 


[]Yes 


CMH 5 


map embedded strings from H.323 to QSIG 
names 




M 


8.3.7 


[]Yes 


CMH 6 


map RQSE APDUs from H.323 to QSIG 




M 


8.4 


[]Yes 


Comments: 
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